-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Proposal: Result Codable conformance and async init #2741
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: YOCKOW <[email protected]>
Co-authored-by: YOCKOW <[email protected]>
Thanks for the fixups :) |
/// | ||
/// - Parameter body: A potentially throwing asynchronous closure to evaluate. | ||
@_alwaysEmitIntoClient | ||
public init(catching body: () async throws(Failure) -> Success) async { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes please!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
|
||
## Motivation | ||
|
||
The Result type is often used to bridge between async and not async contexts, and it may be useful to initialize a `Result` from the result of an async computation, to then pass it along to other non-async code without unwrapping it first. This is currently inconvenitnt because the `init(catching:)` initializer is missing an `async` overload. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Result type is often used to bridge between async and not async contexts, and it may be useful to initialize a `Result` from the result of an async computation, to then pass it along to other non-async code without unwrapping it first. This is currently inconvenitnt because the `init(catching:)` initializer is missing an `async` overload. | |
The Result type is often used to bridge between async and not async contexts, and it may be useful to initialize a `Result` from the result of an async computation, to then pass it along to other non-async code without unwrapping it first. This is currently inconvenient because the `init(catching:)` initializer is missing an `async` overload. |
This is a proposal to add:
catching:
initThe combination of those allows "catching" an async computation and have the result be Codable if the error also was.